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FOREWORD 


The Software Engineering Laboratory (SEL) is an organization 
sponsored by the National Aeronautics and Space Administra- 
tion Goddard Space Flight Center (NASA/GSFC) and created for 
the purpose of investigating the effectiveness of software 
engineering technologies when applied to the development of 
applications software. The SEL was created in 1977 and has 
three primary organizational members: 

NASA/GSFC (Systems Development and Analysis Branch) 

The University of Maryland (Computer Sciences Department) 
Computer Sciences Corporation (Flight Systems Operation) 

The goals of the SEL are (1) to understand the software de- 
velopment process in the GSFC environment? (2) to measure 
the effect of various methodologies, tools, and models on 
this process? and (3) to identify and then to apply success- 
ful development practices. The activities, findings, and 
recommendations of the SEL are recorded in the Software En- 
gineering Laboratory Series, a continuing series of reports 
that includes this document. A version of this document was 
also issued as Computer Sciences Corporation document 
CSC/TM-80/6154. 

Contributors to this document include 

Todd Welden (Computer Sciences Corporation) 

Mike McClellan (Computer Sciences Corporation) 

Paul Liebertz (Computer Sciences Corporation) 

Single copies of this document can be obtained by writing to 

Frank E. McGarry 
Code 582.1 
NASA/GSFC 

Greenbelt, Maryland 20771 
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ABSTRACT 


This report concerns itself primarily with the compatibility of the 
Multimission Modular Spacecraft (MMS) Ground Support Software System 
( GSSS ) / currently operational on a McdCcmp IV/35, with the VAX 
11/780 system. The compatibility is examined in various key areas 
of the GSSS through the results of in-depth testing performed on 
the VAX 11/780 and ModCcmp IV/35 systems. In addition, the com- 
patibility of the GSSS with the ModComp CLASSIC is presented based 
upon projections from ModComp-supplied literature. 
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section l - raraocacrxcN 


The Multimission Modular Spacecraft (MMS) Ground Support Software 

System (GSSS) was developed and is currently operational in a 

ModCcmp IV/35 hardware and software environment. The dependencies 

of the GSSS upon this environment have previous!// been enumerated 

1 

in the MMS/GSSS ModCcmp Device and MAX IV Dependency Study. This 
compatibility report concerns itself primarily with the compatibility 
of the currently operational GSSS with two more advanced minicom- 
puters with approximately the same capabilities as the ModComp IV/3S: 
the ModComp CLASSIC and the DEC '/AX U/780, The compatibility is 

examined through the results of in-depth testing in the various 

. _ • 

key areas oc the GSSS performed on both the ModComp IV/35 and 
VAX 11/780 systems* In addition, t;he compatibility of the GSSS 
with the ModComp CLASSIC is presented based upon projections from 
MoaComp-supplied literature and discussions with ModComp CLASSIC 
users. The most significant portion of the compatibility study 
• involved the transporting of the STOL module and a few associated 
"key- in" modules, from the ModComp to the VAX, It was through • 
this vehicle that the important areas of GSSS intertask conmuni- 
cation and activation were investigated. Additional differences 
in the FORTRAN language implementations were also discovered during 
the transport of the STOL module. Since the STOL module has been 


CSC Document# CSC/TM-80/6013 , "Multimission Modular Spacecraft Ground 
Support Software System (MMS/GSSS) MODCCMP Device and MAX IV Dependency 
Study", T. Welden and M. McClellan, December 1979. 
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successfully transported to the VAX system, this can be used as 
a nucleus of the VAX version of the C3SS should the decision be 
made to transport the entire system. 

» 

This report describes the methods used in gathering the data, the 
compatibility of the peripheral devices, the results of the testing, 
the compatibility of the application languages, and the compatibility 
of the vendor supplied software, and annotates pertinent conclusions 
based upon the data gathered. 
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SECTION 2 - METHODS USED IN GATHERING CATA 


The compatibility of the ModComp implementation of the GSSS was 
studied primarily through computer-based testing on the ModComp 
IV/35 and VAX-11/780 computers. These test3 consisted of small 

specific benchmarks - to be referred to simply as the benchmarks - 

* 

and a larger benchmark: the 5T0L module implementation. 

The benchmarks tested three general areas: I/O and file manipulation, 
FORTRAN programming language semantics, and timing the overhead of 
common but sometimes crucial operations. The I/O and file manipula- 
tion tests concerned sequential and random disk files, formatted and 
unformatted tape files, and tape file positioning. The FORTRAN pro- 
gramming language -tests concerned the memory representation, manipu- 
lation, and comparison of numbers and character strings, as dependent 
on their definition in DATA statements, variable data types, array 

« 

EQUIVALENCE ing, and compiler options. Also tested in the FORTRAN 
language was array storage organization.. Finally, the timing bench- 

* 

marks covered polynomial evaluation and the overhead involved in the 

t 

following operations: READ/WRITE for mailboxes (message passing), 
CPEN/CLCSE and FEAD/WRITE for files, FORTRAN subroutine calls, and 
system services. 

The 5TOL module implementation, while using the knowledge gained from 
the benchmarks, focused on developing the systems programming tech- 
niques needed to run GSSS processes (rasKs) under real-time control. 


' 5 -1 
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The techniques are: 

• Interprocess (intertask) communication 

• Process (task) activation 

• Shared (global) regions. 

jk 

All three techniques employ system services and utilities. The first 
two do so via a developer-written host-system GSSS library routines, 
while the third uses the host system utilities. Table 2-1 sunmarizes 
the information about the MCCCCMP software (i.e., library routines, 
and the P£X services they reference) used to realize these techniques; 
it also gives the corresponding VAX system services (or library rou- 
tines) used. In this table the VAX term, process, is used in place of 
the equivalent ModComp term, task. 
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Table 2-1. Software for Process Ccnriunication/Activation and for 

Shared Regions (1 of 2) 


i Function 

MODCCMP & VAX 
Routine Name 
{REX Service) 

1 

» 

VAX 

Svstem Service Used 

Send a message 

SNDMSG 

CREMEX: create a mailbox 

to another process. 

(SEND) 

QIO: write message to mail- • 
box 

Receive a message 

RECVMS 

GETJPI: retrieve infomation , 

sent from another 
process by SNDMSG. 

(RECEIVE) 

about a process (e.g., : 
process name). 

ASSIGN: Assign I/O channel 1 
to a mailbox. 

QIO: read message from 
mailbox , 

Activate a process 

ACTTV8 

CREPRC: create a process. - 

* 

» 

inmed lately. 

(ACT) 

Suspend a process 

WAIT 

* i 

SETIMR: set an event flag 

for a specified 
period of time. 

(DELAY) 

.after a specified 
period of time. 

WAITER: place calling pro- 
cess in wait state 
until event flag is 
set. 

Retrieve information 

INF04 

GETJPI: retrieve informa- * 

about a process. 

1 

(GEITASX) 

tion about a process. 
(Not totallv comcati- 
ble with MODCCMP) . 

| Convert 3-character 

-SCAN 

CSSS library routine seed- 

ASCII string to 
CANCCDE. 

(ATCANJ 

allv written for the 
VAX'. 

Convert 6-character 

ISDCAN 

GSSS library routine seed- 

ASCII string to 
CANCCDE. 

\ 

(ATCAN) 

ally written for the 
VAX. 


i - 0 
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Table 2-1. 


Software for Processing Corrmunication/Activation ar,d 
for Shared Regions (2 of 2) 


i 

■ Function 

I 

I 

i 

t 

[convert 3-character 
jCANCQDE to ASCII 
I string. 

i 

I 

l 

i 

I 

i 

'Convert 6-character 
CANCOOE to ASCII 
string. * 


MCECCMP & VAX 

Routine Name VAX 

( REX Service) SV3tem Service Used 


CECAN3 GSSS library routine speci- I 
(CANTA) ally written for the j 

Vax. (This function i 
not needed on MCECCMP | 
GSSS) . 


DECAN 6 GSSS library routine speci- 

( CANTA) ally written for the 

VAX. (This function 
* not reeded on MCECCMP • 

GSSS) * 


* 
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SECTION 3 - COMPATIBILITY CF PERIPHERAL DEVICES 


The standard peripheral devices that are necessary to support the 
GSSS in the MocComp iv/35 environment consist of a moving head disk, 
a fixed head disk, two 9 tjrack magnetic tape drives, one KCHT control 

i 

console, at least two KCRT display consoles, a card reader and a 
printer. In addition to these standard devices there are specialized 
devices: four parallel I/O ports for telemetry and commanding, one A/D 
input port, and 16 D/A output ports. 

Since it was not expected that any other machine used for benchmark 
testing would have the specialized devices attached, this report 

addresses only the areas of standard peripheral devices. 

* 

3.1 MAGNETIC TAPE DRIVES 

11 1 • * 

The ModComp IV/35 system* i3 currently configured with two 9 track, 

t 

75 inches per second magnetic tape drives. One operates only at 900' 
BPI . The other is dual density and operates at either 300 or 1600 
BPI. The '/AX is configured with one dual density tape drive. Any 
I/O reference to any tape drive on the ModComp will cause I/O to be 
attempted to that drive, No special Job Control Language (JCL) com- 
mands or coding techniques are required to accomplish this (other 
than assigning the tape drive) . 

On the ModComp CLASSIC system the tape drives operate identically to 
those on the ModComp IV/35 from the users standpoint. 
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Cn the CEC VAX U/780, however, tap* access is accomplished with an 
entirely different philosophy, Any tape is considered a new "volume”, 
just like mounting a different disk pack under supervisor control. 

This philosophy forces the user (without special coding in assembler) 
to issue a mount command in order to access the cape drive. Xn 
addition, the default tape format is '’standard ASCII labeled” format 
which is not expected or accepted by any (nodule of the GSSS. The 
GSSS expects all tapes to be unlabeled. This can be accomplished on 
the VAX by explicitly requesting "UNLABELED” on the mount command. 
Another aspect of the tape drive configuration that differs from the 
McdComp on the VAX is tape density (800 or 1600 BPI). Cn the ModCcmp 
the density is set manually by a switch on the tape drive unit, 

'this removes the concern about tape density ( from the program and its 
assignments. However, on the VAX the tape density must be specified 
on the mount command. This implicates different sets of JCL ccnsnands 
for any program accessing tapes that can be of either: density. 

. There is one more difference implicated by the VAX tape philosophy. 

Cn the ModComp any number of assignments from one or numerous pra* 
grams can be made to the saift$ tape drive using only assignment state- 
ments. Cn the VAX this can be accomplished out requires a special 
JCL sequence as follows: 

ICCNT/NOIABEL/ DENS IT¥*B 0 0 MTAO : FOR004 FOROG4 
$ ASSIGN FCR004 FCR003 
5 ASSIGN FOR004 FOR006 
SCPEM/WRITS FCR004 MTAO; 
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This sequence assigns the FORTRAN logical units 3/ 4 and 6 to the 
tape drive MTAQ. Mote that this tape is opened for writing and 
reading. If another process wishes to access it or later additional 
assignments must be made, a $ CLOSE JCL command must be issued and 
a new JCL command sequence input. In addition, all processes access- 
ing the tape must explicitly "OPEN" it as "shared". 

% 

3.2 KCRT DISPLAYS 

The KCRT displays on both ModComp systems and VAX system appear to be 
compatible when displaying information, However, due to the different 
set up of the keyboard there 13 a compatibility problem. On the 
ModComp systems the keyboards operate in .message mode, transmitting a 
complete line of text on each transmission. On the VAX they operate 
in character mode transmitting one character at a time as each is typed. 
This mode of operation precludes updating display screens while an ip- 

> i 

put request is pending on that device. This problem can probably be 
overcome with some specialized coding techniques for KCRT input in- 
volving queuing she characters until the entire string is input. 

Further analysis needs to be done in this area. 

» 

3.3 CISK FILES 

The MooComp IV/35 is currently configured with one 24-megabvte moving 
head disk and one 2-megabyte fixed head disk, each with a sector size 
of 256 bytes. The ModComp CLASSIC can have disks of a similar nature. 
The VAX 11/7SQ used for the benchmark testing is equipped with cr.e 
175 megabyte moving head disk with a sector size of 512' bytes. 
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Accessing the disks on any of the machines requires no special coding 
techniques. Cn the ModComp IV/35 disk files are a fixed partitioning 
of the disk determined at "Sysgen" time. The disk files can also 
be generated this way on the ModComp CLASSIC. On the VAX 11/780, 
and optionally on the ModComp CLASSIC, disk files can be dynamically 
allocated. This dynamic allocation of disk files is a desirable 
feature. However, on the VAX system, di3k files are dynamically alloc- 
ated automatically by simply opening a file for output. Without 
' special coding techniques to avoid this, the proliferation of files 
could be colossal on a real-time system like the GSSS since many 
tasks write to disk files and then exit (e.g. 08C dump collector). Cn 
the VAX, each time one of these tasks ran, a new file would be created. 

Cn the ModComp IV/35 the access method used on any file can be se- 
quential or random and the physical files can have any number of 

$ 

end-of-file marks. Cn the VAX system random files cannot have any ' 
end-cf-file marks. This may effect the conmand processing in 
■ the GSSS. However, the VAX system provides for automatic 
record blocking to and deblocking from the disk files while the 
ModComp IV/35 does not. 

3.4 LIME PRINTER 

The ModComp IV/35 system is equipped with a 600 line per minute 
printer. The VAJ< 11/730, used for the benchmark tests, is equipped 
with a CECWRITER III for printing which is much slower. Other 
than for speed, these two devices appear to be totally compatible 
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for printing ASCII characters. However , to operate effectively 
the GSSS will require a printer with at least the capability of 
600 lines per ’minute (100 mls/line) , 

t 

3.5 CARD READER 

The ModComp IV/ 3 5 system is equipped with a 30C card per minute 
card reader. The VAX 11/780 is not equipped with a card reader. 
Therefore no statement can be made other than that the fully oper- 
ational GSSS requires a card reader in its current configuration 
(e.g. for, DBPARS, DBXREF, BLDTAB, BLEHAZ, etc.). 
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SECTION 4 - RESULTS OF TESTING 


During the course of the compatibility study, numerous tests have 
been run on both the ModComp IV/35 and VAX 11/780 computer systems* 
All of these benchmark tests have been accomplished using the 
FORTRAN language. Many obstacles had to be overcome during the cun- 
ning of these tests, partially due to the differences in the two 
systems, and partially due to incompatibilities in the FORTRAN lan- 
guage. The VAX system is a secure system, isolating each user from 
the others, and retiring privileges and quotas for each user. The 
ModComp system requires no privileges for any user and any user can 
do anything with the system. These* differences 'between the systems, 
impacted the testing greatly in the areas of task activation and „ 
communication. The differences between the FORTRAN language imple- 
mented on both* machines impacted the testing in the areas of Input/ 
Output (I/O), file manipulation, and internal data organization, 
representation and manipulation. 

This section of the report describes these obstacles and annotates 
the results of the benchmark, tests. 

4.1 I/C BENCHMARK TESTS 

The I/O Benchmark Tests were run on both the ModComp IV/35 and VAX 
11/780. They examined all of the areas of I/O that are commonly 
used by modules in the CSSS. Many of the "normal" I/O methods used 
on the ModComp system did not operate in the same way oh the VAX 
system. These compatibility problems are accounted for in the 

4 1 ORIGINAL PAGE Vi 
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following sections. Note that all the benchmark tests were done 
using the FORTRAN language. 

4.1.1 GENERAL I/O INFORMATION 

The MoaComp IV/3S and VAX 11/780 differ greatly in their I/O 
philosophy, On the ModCcmp it is only necessary to assign a logical 
name to a device or disk file name in order to attempt accesses to 
that device or file. If the device or file is not available for 
access, an error message is output by the supervisor and the program 
is placed into a "held" state. However, on the VAX , access to a 
device is denied unless the device is explicitly "mounted" in the 
code or through JCL commands (sets section 3.1). If the device is not 

mounted the program is aborted by the supervisor. On the ModComp,’ 

* 

any or all programs can share any device or disk file by simply 
assigning logical names to the same device or file name, and no pro- • 

t 

gram can guarantee that it has exclusive use of that device or file. 
Cn the VAX, however, the opposite is true. Programs, by default, 
obtain exclusive use of a device or file as long as they have it 
"opened". Only by using special VAX coding techniques can more than 
one process access the same device or file at the same time. This 
is accomplished by using the special VAC FORTRAN OPEN statement fully 
specifying the file name and specifying it as SHARED: 

(e.g., OPEN (UNIT* 3, NAME* 'FILE. CAT ? I' , SHARED)) 
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Sven this method will work only for input files to multiple processes. 
Output files cannot be shared for output by more than one process. 

The resulting data on the file is unpredictable using sequential 
access. Some of the records are never written to the file. This 
can have an effect on the dump collection modules in the GSSS. 

4.1.2 SEQUENTIAL DISK FILE I/O 

Except for shareability and sector sizes, the sequentially organized 
disk files on both the ModComp and VAX systems operate in much the 
same ways 

• Both systems can have multiple end-of-file marks on 
one physical disk file. 

• Both systems can randomly read a sequentially created 
disk file as long as the records are of fixed length. 

« 

« 

• Both systems can add records at the end of the file. 

• Logical record lengths of 256 bytes can be read 
and written on both systems. 

However there are some differences between the two systems. Some 
things that are cone on the VAX system but not done on the ,'tedComp 
system are: 

• Blocking and deblocking is automatically done by the 
supervisor . 
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• File sizes ace dynamically expanded as cecocds are added 
to the file. 

• The I/O from one process is isolated from other processes 
(unless special JO* contnands are used), 

• Files are dynamically created when written to for the first 
time. 

• Evidence of the last updated version of a file is kept in 
the file directory, including date and time. 

In contrast there are some operations effecting sequential files that 
can be performed on the ModCcmp system that cannot be done cn the 
VAX: 1 * 

• Sequential I/O can update individual records on a disk file. 

• Random writes can be made to a sequentially created file. ' t 

• File pointers (keys) can be positioned to any particular 
record by either advancing or backspacing over, end-of- 
file marks or records (i.e. AVF, AVR, 3K? s 3KR utilities). 

• Files need not be explicitly opened to indicate access mode 
(i.e. sequential or random), 

Some of these differences can have a great effect on the GSSS soft- 
ware; others are of little consequence. Only through attempting to 
transport the GSSS to the VAX can all obstacles be found. The VAX 
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philosophy of dynamical ly allocating, files may be the greatest ob- 
stacle to overcome since none of the GSSS software expects this to 
ever occur { see Section 3.3), 

4.1.3 RANECM DISK FILS I/O 

Except for the sector sizes and automatic blocking and deolocking, 
random access disk files operate in much the same way on both the 
ModComp and VAX system: 

• Both systems allow random updates anywhere in the file 
using the same "key'* values. 

« Bath systems allow sequential reads from a randomly created 
file (as long as the records are continuous). 

» Logical records of 256 bytes can be accessed on both machines. 

However, some things can be accomplished on the VAX system 
that cannot on the ModComp are: 

• Fixed record lengths of other than 256 bytes can be accessed. 

<• Cue to automatic file size expansion, records can be added 
past the end of the file. 
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In addition tne VAX system has one limitation that the ModComp 
system does not: 

• Any file used for random access can have only one end-of-file 
and this end-of-file must be after the last record in the file. 

Conversely, there are things that can ce done on the McdComp system 
and not on the VAX system: 

• Sequential updates can be made to a randomly created file. 

• Randomly accessed files can have many end-of-file marks. 

• Record lengths are fixed at 256 bytes. 

Probably only one of these differences will impact greatly the transport 
of the GSSS. The allowance by the ModComp system for multiple ehd-of-file 
marks on a randomly accessed file. In many cases, in the GSSS, files 

r 

with more than one end-of-file mark are created sequentially but 
input randomly. This can have an effect on the database and commanding 
modules of the GSSS. 

4.1.4 FORMATTED TAPS I/O 

Cnee a tape is mounted and positioned properly, the records written 
to tape, or read from tape, with FORTRAN formatted reads and writes, 
are totally compatible on both the ,'lcdCom? and VAX systems. However, 
there ar a some problems with compatibility in the areas of tape 
positioning and a nd-o£-file marks. 
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The FORTRAN RESCIND command is not compatible; 


• On the MocCcmp system a REWINE of any tape merely positions 
the tape at the "load point". 

* 

• Cn the VAX system 4 REMIND of a tape causes two end-of-file 
marks to ce written at the beginning of tape and the tape 
is positioned immediately following them, if the tape is 
"unlabeled" . 

There were other problems encountered during the formatted tape I/O 
testing on the VAX system; 

• 256 byte records have not been successfully written to un- 

labeled tapes using FORERAN formatted writes. 

• » 

• Tapes must be explicitly mounted using JG L commands before 

•they can be accessed ( see Section 3.1), 

m 

The physical end-of-file marks written to tapes are compatible to 
' both systems , however : 

• End-of-file marks written by the ENDFILE function on the 
VAX system are not a. I wavs recognized as end-of-files on 
FORTRAN read statements with "END*" specified, on the 
VAX. The end-of-file mark is sometimes ignored by the 
I/O system if it was the last thing written to the tape. 

Any module of the GSSS that reads tapes ' e . g . FL3K, 

STOLPH) can be effected by this. 


ORIGINAL PAGE IS 
OE EPOR .QUALITY 



4.1.5 UNFORMATTED TARE I/O 


When using standard FORTRAN reads and writes on both the ModCcmp and 
VAX systems, unformatted tape records are totally incompatible, The 
FORTRAN generated record headers are different as shown below? 

• Record headers for 36 byte records; 

VAX ModCotnp 

X* 0022’ , X' 003 ' X'0700', X* 0024 * 

In addition to the record headers and tape positioning problems pre- 
viously mentioned in Section 4.1.4, there is a problem with end-of- 
file marks on unformatted tapes on the VAX: ^ 

0 • * 

• Unformatted, unlabeled tapes cannot have an end-of-file 

mark written to them from Fortran using the ENDFILE function. 

Attempting to do so causes an I/O error and terminates the < 

« 

process, 

' 4.1.6 FILE POSITIONING FUNCTIONS 

The McaComp system allows for all the file and record positioning 
functions using JCL comnands: 

4 Advance File (AVT) 

• Advance Record (AVR) 

• Backspace File (BKF) 

• Backspace Record (3KR) 
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The VAX system dees nor. allow for any of them. In addition there 13 
the REWIND problem stated previously in Section 4,1*4, Since many 
modules within the GSSS (e.g. CBGEN, CBXREF) use these functions this 
can have a great impact on the transporting of the GSSS to the '/AX, 
However, all of the above functions can be accomplished with simple, 
specialized library routines , or special SQIO calls. 

4.1.7 EVENT PRINTING 

The philosophy of printing event messages differs between the ModComp 
IV and VAX U/780 computer systems. On the ModComp system event mess- 
ages are easily output in chronological O'Mer simply by closing or 
endfiling the output stream after each line. When this is done the 
messages ace sent to the spooler and concatenated with all other mess- 
ages and then actually printed. The ModComp makes no attempt to isol- 
ate one task's printout ffom another's when this method is used. 

* l 

« 

On the VAX system, the spooler groups each process' output secar- 
• ately and prints the lines as separate listings for each process. 

Using the ModComp method on the VAX results in each line being out- 
put to a "new page" on the printer. However, there is a method 
that can be used on the VAX system to insure event messages are 
neatly printed in chronological order. 

This can be accomplished by routing all printer event messages to 
one process through a mailbox. Cnee a message is received by this 
process (through the mailbox) it can be printed in the normal manner. 
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However, there is one more oddity of the VAX system print spooler. 
Unless this process keeps count of lines printed and closes its 
spool file,* after each page of printout (approximately every 50 
lines) , or periodically, no lines will be actually printed until this 
process exits. A preliminary version of this process already 
exists on the VAX. 

4.2 FORTRAN LANGUAGE BENCHMARK TESTS 

The FORTRAN language tests fall into three categories: arithmetic 
and logical operations, array allocation, and the logical and physi- 
cal organization of numbers and character strings. Some of thesJ tests 
established compatibilities, while others revealed serious and poten- 
tially widespread incompitibilifeies between the ModCcmn TV/35 
and -the VAX 11-780 with respect to the GSSS. 

4.2.1 ARITHMETIC AND LOGICAL OPERATIONS 

* I 

t 

• There exist integer arithmetic calculations which are valid 

» 

and which work on the ModCcmp but which cause overflow and 
abort the process on the VAX ( Seie Section 5.1). 

• The LOGICAL*!. (L*l) data type on the VAX works 

like any other integer date type for integer arithmetic 
and logical operations, including conversion (i.e., 3ign 
extension, etc.). Note that this data type does not 
exist in ModComp FORTRAN and should not be used when 
transporting modules to the VAX. 
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• The FORTRAN supplied functions ICR, LAND, and ISHFT work 


the same for integers on the ModContp and the '/AX, This was 
verified by extensive bit extraction/insertion and shifting 
tests, However, their use in character manipulation leads to 
different results on the two computers (See Section 4.2.3). 

e Any differences in the accuracy of floating point calculations 
between the ModComp and the VAX are too small to affect their 
application in GSSS. As an example, least squares calculations 
typical for GSSS were performed on the two machines and agreed 
to four to six decimal places tfor 6-term/ll -point formulas 
thru 2-term/5™point formulas. This was two to four places 
more accurate than the anoroximatiQn formula to the correct 
solution. 

> 

4.2.2 ARRAy ALLOCATION 

t 

r 

• The assignment of the elements of one-dimensional FORTRAN 
arrays is in their logical order on both machines. For 
example, the VAX FORTRAN data declarations: 

LOGICAL*! W(8) 

INTEGER* 2 X(4) 

INTEGER* 4 Y(2) 

REAL*8 Z(l) 

EQUIVALENCE (W{1) ,X(1) ,Y(l) ,Z(1) ) 

assign these arrays to the same eight bytes of memory with 
the following element correspondence: 
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Table 4-2. Array Elements Correspondence 



This memory correspondence also holds on the ModComp for arrays X,Y, 
and Z, but not^for W since the L*1 data type doesn't exi3t on the 
ModComp. Note that on both the ModComp and the TAX the address of a 
variable or an array is presented as the address of its lowest 
addressed byte in memory even* though the ModComp is a word 
addressing machine ( 16 bit words ) . 

* 

• Cn both machines the allocation of the elements of two- 
dimensional arrays is column major order (the FORTRAN stan- 

. dard); that is the elements A(I,J) are taken by varying 
the leftmost subscript (I) most frequently and the rightmost 
subscript (J) least frequently. 

4.2.3 BYTE COMPOSITION OF NUMBERS AND CHARACTER STRINGS 

• The storage of alphanumeric character strings in arrays 
by FORTRAN statements (i.e., DATA or READ) results in 
the same physical ordering of bytes in memory for each 
data type and for both the ModComp and the VAX computers. 
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As an example, consider the assignment of the character 
string "ABCDEFGH" to each of the arrays W, x, y, z (declared 
in Section 4.2.2) by the following FORTRAN statements: 

DATA M / 1 A * - * ft l i u • / 

or READ (5, 10) w f With 10 FORMAT (8A1) 

DATAX/'AB', 'CD', 'EF\ 'GH'/ 
or READ (5,10) X with 10 FORMAT (4A2) 

DATA Y/ 'ABCD' , ' EFGH'/ 
or READ (5,10) Y with 10 FORMAT (2A4) 

DATA Z/ 'ABCDEFGH'/ 

or READ (5,10) Z with 10 FORMAT (A8) 

The result is summarized in Table 4-3. Recall that the LOGICAL *1 
data type (e.g., array W), exists only on the VAX. Also, we are not 
considering the CHARACTER data type, which exists only on the VAX. 

Table 4-3. Byte Ordering for Character Strings 
ModCcmp and VAX (Arrays W, X, Y, and Z) 


Logical Byte Order: 

A 

B 

C 

D 

E 

F 

G 

H 

Byte Addresses: 

a 

a+1 

a+2 

a+3 

a+4 

a+5 

a+6 

a+7 

Hex Codes: 

41 

42 

43 

44 

45 

46 

47 

48 
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• The storage of an integer at the byte addresses for 
an integer variable differs on the ModCcmp and VAX 
computers. Considering a FORERAN integer as a se- 
quence of bytes, the bytes are stored in decreasing 
order of significance on the McdComp (i,e., most 
, significant byte at the lowest byte address) and in 
increasing order of significance on the VAX (i,e., 
least significant byte at the lowest byte address). 

For example, consider the following integer 
{ hexadecimal ) value assignments to the arrays W, X, 
and Y from Section 4.2.2: 

DATA W/Z4X, £42, Z43, Z44, Z45, Z46, Z47, Z48/ 
or READ (5,10) W with 10 FORMAT (8Z2) 

DATA X/Z4142, A4344, Z4546, Z4748/ 
or READ (5,10) X with 10 FORMAT (4Z4) 

DATA Y/Z41424344, Z4S464748/ 
or READ (5,10) Y With 10 FORMAT (2Z8) 

, The READS refer to the hexadecimal string "4142434445464748". 
Table 4-4 compares the internal storage representations of these 
integers for the ModComp and VAX computers and also shows the 
bit-numbering conventions for the two computers (they are the 
reverses of each other within data items). Note: The sign bit 

of a data item is denoted by s. Also, the address of a data item 
for both the ModComp and the VAX is its lowest byte address. 
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Table 4-4. Byte Ordering for Integers 


t 




L*1 array W (VAX only) 

* 



Array Element 

» 

* 

W(l) 

W( 2) W( 3) W(4) W(5) W(6) W(7) W(8) 


Logical Byte Order 

* 

3 41 

s42 

s43 s44 

s45 s46 

s47 s48 


Bit Numbering 

• 

* 

0-7 

0-7 

0-7 0-7 

0-7 0-7 

0-7 0“ 

■7 


Byte Addresses 

• 

• 

a 

a+1 

a+2 a+3 

a+4 a+5 

a+6 a+7 





1*2 

array X 





Array Element 

• 

• 

X(l) 

X( 2)‘ 

X(3) 

X(4) 


Logical Byte Order 

« 

* 

( s41 

42) 

(s43 44) 

(s45 46) 

(s47 

48) 


Bit Numbering MOD 

• 

• 

0-7 

8-15 

0-7 8-15 

0-7 6-15 

. 0-7 

8-15 


VAX 

• 

15-8 

7-0 

15-8 7-0 

15-8 7-0 

15-8 

7-0 


Byte Address MOD 

• 

• 

a 

a+1 

a+2 a+3 

a+4 a+5 

a+6 

a+7 


VAX 

• 

• 

a+1 

a 

a+3 a+2 

a+5 a+4 

a+7 

a+6 

1 

i 




1*4 

array Y 





Array Element 

• 

• 



m) 


Y(2) 



Logical Byte Order 

• 

• 

(s41 

42 

43 

44) ( 345 

46 

47 

48) 

Bit Numbering MOD 

• 

• 

0-7 

8-15 16-23 

23-31 0-7 

3-15 

16-23 

24-31 

VAX 

• 

3.1-24 23-16 15-9 

7-0 31-24 

23-16 

15-8 

7-0 

Byte Addresses MOD 

• 

a 

a+1 

a+2 

a+3 a+4 

a+5 

a+6 

a+7 

VAX 

* 

• 

a+3 

a+2 

a+1 

a a+7 

a+6 

a+5 

a+4 


• These differences in the allocation of integer data tyres 
are transparent to the FORTRAN programmer except when 
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programing techniques are used which require operating with 
only part of a data item. One such case is the manipulation 
of parts of an integer (i.e., sign, most significant part, 
least significant part, etc.) by equivalencing arrays and 
variables of different data types. For example, suppose the 
following equivalences are made for the arrays W,X, and Y, 

EQUIVALENCE (W(l) ,X( 1) ,Y( 1 ) ) 

Table 4-5 summarises the semantic differences between the ModComp 
and VAX computers which occur in the elements of array X. Clearly, 
programs performing such manipulations will not work the same on 
both machines. 

Table 4-5. Byte Manipulation of Integers 


Part of Y(l) 

ModComp ref. 

VAX ref. 

Most Significant Half : 

X(l) 

X(2) 

Least Significant Half: 

X(2) * 

XU) 

Sign: 

X(l). 

X( 2) , W(4) 

Most Significant Byte: 

^ 

W(4) 

Least Significant Byte: 

— 

• W(l) 


• In a similar way, the difference in allocation of 
floating point numbers, coupled with equivalencing 
variables of other types with floating point type 
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variables, can lead to semantic differences in 
ModCcmp and VAX FORTRAN programs. For example, 
consider setting the less significant part of 
the mantissa of a double-precision floating point 
number P via an equivalenced 1*4 array Y( 2) ; the 
bytes of element Y(2) will not be in the same 
order as those of the less significant half of P. 

e Another case of semantic differences due to the allocation 
of integers occurs in character manipulation. Character 
strings can be constructed or modified in FORTRAN by arithmetic 
or logical operations. The following FORTRAN statements 
define the same string in 1*2 variables X(l),* X(2): 

• 

X(l) « 65*256 + 66 , X(2) '« 67*256 +68 
or 

X(l) - IOR(ISHFT(65,8) , 66)), X(2) « IOR( ISHFT(67,8) ,68)^ 

♦ 

as do the following in Y(l): 

Y( 1) * ((65*256 + 66) *256 + 67)*256 + 68 

Y(1 ) * IOR( ISHFT( ICR( ISHET( IOR( ISHFT( 65 ,8 ) , 66 ) , 

8), 67), 8), 68) 

However, the logical ordering of the characters within the integers 
in memory differs: 

• Cn the ModComp the above produce the equivalent of 
the data statements: 

and 


DATAX/'AB', 'CD'/ 
DATA Y/'ABCD'/ 
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• Cn the VAX they produce the equivalent of: 

DATA X/’BA', 'CC7 and 
DATA Y/'DCBA'/ 

* 

This results in different logical memory layouts as shown in Table 
4-6, assuming that the arrays are equivalences! . Mote that 65, 56, 
67 and 68 are the decimal character codes for A, a, C and D, 

Table 4-6. Logical Character Strings Resulting from 
Arithmetic and Logical Operations 


• 

ModComp 

VAX 



Byte Address: 

a a+l 

a+2 a+3 

a+3 a+2 

a+1 a 


1*2 X Character String: 

A B 

C D 

C D 

a a 

* 

Array Element: 

X(l) 

X<2) 

X(2) 

X(l-) 


1*4 Y Character String: 

A 3 

. C D 

A B 

C D 



In addition, the logical order of characters within integers (which 
■ corresponds to the ordering of bytes in memory) is the same as A-format 
input and differs on the two machines, as illustrated in Table 4-7. 

Table 4-7. Character Strings by Input in A Format 



ModComp 

VAX 

Byte Addresses 

a a+1 

a+2 a+3 

a+3 a+2 

a+1 a 

1*2 X Character String: 

A B 

C D 

D C 

3 A 

Array Element : 

X(l) 

X( 2) 

X( 2) 

X(l) 

1*4 Y Character String: 

A B 

C D 

D C 

3 A 
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The implications of these semantic differences between the ModComp 
and the VAX are obvious. Since these kinds of programming techni- 
ques are allowable in the FORTRAN language, they may be used any- 
where in a program and, hence in a large program system like the GSSS 
there may be numerous ModComp dependencies due to character and 
number manipulation occurring throughout the software. 

4.3 TIMING BENCHMARK TESTS 

Several timing tests were performed on the VAX on common but impor- 
tant code sequences. The purpose was to determine if any potential 
timing problems might occur in the GSSS due to these computations. 
These tests along with their corresponding average times (over 100 
to 100,000 executions as appropriate) are presented in Table 4-8. 

Unless otherwise stated, the tests were coded in FORTRAN and the 
times are in milliseconds (ms). In general these times are com- 

< 

parable to those on the ModComp. The only potential problems are, 

, the outrageously long time for the file OPEN/CIOSE sequence (314 ms), 
and the time for the mailbox WRITE/READ sequence (.4 ms). We note 
that the VAX microcoded MACRO instruction for polynomial evaluation 
is five times as fast as efficient FORTRAN code. 


4-19 


ORIGINAL PAGE IS 
Of POOR QUALITY 


Table 4-8. Timing Benchmarks 


Test Performed 

Time (ms) 

5-th Order Polynomial Evaluation 


(Horner's Method): 


- FORERAN OO-loop 

0.11 

- Special VAX microcoded 

0.02 

instruction (POLY) 


FORTRAN subroutine Call Overhead 

0.02 

System Service Call Overhead 

0.07 

Blocked File I/O: 


- READ 

3.3 

- WRITE 

4.0 

Mailbox Write/Read Sequence 

0.40 

File OPEN/CLOSE Sequence 

314.0 
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SECTION 5 - COMPATIBILITY OF APPLICATICNS LANGUAGES 


In the ModComp IV/3S version of the GSSS only two applications 
(programming) languages are used: FORTRAN IV and M4A Assembler. 

The ModComp CLASSIC system is totally compatible with these two 

m 

programming languages. In fact, the object language from the 
ModComp IV/ 35 will execute on the ModComp CLASSIC. On the other 
hand, the VAX 11/780 system has a different implementation of FORTRAN 
(FORTRAN IV- PLUS) and its assembler language is entirely different. 

5.1 FORTRAN 

The difference in the implementation of the FORTRAN language on the 

ModComp* systems (IV/35 & CLASSIC) and the VAX 11/780 system are 

* 

varied. There are many things that are allowed and done by GSSS 
modules on the ModComp system that cannot be done or don't work the 
same in the VAX implementation of FORTRAN: 

e Modification of DO LOOP variables within the loop is ok on 
the ModComp but not on the VAX. 

• Using SHIFT, AND and OR logic to manipulate .'Characters works 
differently on the two systems. 

• Attempting to convert X 'FFFFA8AA' to a 16 bit integer causes 
overflow on the VAX. 
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• DATA I/Z2Q31/ and DATA I/' 1 '/ are identical foe 16 bit 

variables on the ModComp but not on the VAX. On the VAX it 
is DATA I/Z2031/ and DATA/'l '/ that are equivalent. 

# 

e The ENCODE and DECODE statements have a slightly different 
format. 

e The following code: 

DIMENSION A< 3 ) 

DATA A/' 12 CHARACTERS’/ is ok on the ModComp 
but must be coded as follows on the VAX: 

DIMENSION A(3) 

DATA A/'12CH’ , ’ARAC' , 'TERS'/ 

* 

e The VAX allows for LOGICAL *1 data type, the ModComp does 
not. 

, t 

e The VAX has a special, VAX, CHARACTER data type which must' 
be used to call many system services. 

e The equivalencing of arrays is logically different on the 
two systems (see Section 4.2). 

In addition to the above mentioned compatibility problems, there is one 
major "bug" in the implementation of FORTRAN on the VAX system when it 
is optimized. The following cede sequence produces a value other than 
the zero for the variable J: 


5-2 


ORIGINAL PAGE IS 
OE BQOH .QUALITY 


J«0 

S*,TRUE 
DO 100 >1,10 
IF (B) GOTO 100 
J-I 

100 CONTINUE 
PRINT J 

The effect of this on the GSSS software will remain unknown until each 
and every FORTRAN module is thoroughly tested and debugged on the VAX 
system. 

5.2 ASSEMBLER 

The ModComp IV/35 and ModComp CLASSIC can use the same Macro Assam- 

bier (M4A) . The VAX 11/780, by nature, uses a different Macro 

• * 

Assembler (VAX-11 MACRO). If only the languages were different, 
this compatibility problem could possibly be overcome by writing 
a cross-assembler to assemble the M4A source code into VAX-11 
MACRO code. However, the hardware architecture and language logic , 
differences between the two vendors' machines precludes this approach: 

• The VAX system has 21 different addressing modes. The ModComp 
systems have only 6 addressing modes. 

• Data organizations within memory are logically reversed. 

• The VAX uses stacks for register and argument save areas 
extensively. The ModComp systems do not. 

• Cn the ModComp systems, 15 of 16 general purpose registers 

* 

(Ri - R15) can be used for any purpose, at any time. The 
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VAX system has 4 dedicated general purpose registers (R12 - 
RJ,4 ) and 6 special use registers {RO - R5) leaving only 
6 registers that can be used at any tint/ for any purpose. 

4 

e The instruction logic is entirely different on the ModComp 
and VAX systems. 

e The VAX is a byte addressing machine. The ModComps use 
word addressing. 

This makes the two assembler languages totally incompatible. 

Since over 33,000 lines of M4A assembler code exists in the 
ModComp IV/35 version of the GSSS, this is a major compatibility 
problem with the VAX system. 

5.3 -LIBRARIES 

Except for system service interfaces, the FORTRAN libraries on the » 

i 

ModComp and VAX systems appear to be totally compatible. However, 

• to transport the GSSS to the VAX the entire user written library 
(a large portion of which is written in M4A assembler) must be 
rewritten . 
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SECTION 6 - COMPATIBILITY OF VENDOR SUPPLIED SERVICES 


Both ModCcnrp systems appear to have similar , if not identical, 
vendor supplied services in all areas including JCL commands and 
system services. The VAX system has an entirely different set of 
services. The JCL cciimands on the VAX are more complex and allow 
the user to accomplish more functions but do not include as a sub- 
set all the functions allowed in the ModComp systems. The system 
services are entirely different but do allow for many of the same 
functions . 

6.1 JOB CONTROL LANGUAGE COMMANDS > 

All three systems (ModComp IV/35, ModComp CLASSIC and DEC VAX 11/780) 
provide- the user with Job Control Language- (JCL) commands that give 
the user the capability to control the execution of programs and 
‘maintain data files. Both ModComp systems provide almost identical 
sets of JCL commands to the user. However, the VAX system provides *' 

an entirely different set of JCL commands. Many of the differences 

* 

are merely syntactical differences. Others operate in logically 
different ways. The syntactical differences are easily overcome; 
but the logicg-1 differences are difficult, if not impossible, in 
some cases to resolve. 

Besides the previously mentioned problems with tape mounting and 
assigning logical units for shared use (see Sections 3.1 and 4.1.1), 
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there is one major difference in the JCL conmands that will have a 
substantial effect on the transportation of the GSSS. Xt is in the 
area of the link-editor: 

• Cn the ModComp systems logical unit assignments for a 
"foreground" task can be specified when the program is 
linked. 

e On the VAX system there is no way of specifying 
logical unit assignments when a program is linked. 

This incompatibility is of paramount importance to the transporta- 
tion of the GSSS. In the GSSS no standards for logical unit numbers 
or names have been made and different units are used for the same 
devices and files throughout the system. If the GSSS is transported 
without major changes in this area, special JCL command procedures- 
would have to be run before the execution of each module . The neces- 
sary changes in this area would involve: 

e The examination of each program for the logical units used. 

• The examination of all the link decks for the physical 
equivalents for the logical units. 

• Cross referencing all references to the 3ame physical devices. 

• Changing all the logical unit assignments to a physical 
device to the same unit number or name. This requires 
coding changes within the programs. 
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6.2 SYSTEM SERVICES 


The ModComp systems provide for FORTRAN interface routines in the 
library for calling system services. The VAX system provides for 
calling the system services directly from FORTRAN. Most of the 
major system services available on the ModComp systems have cor- 
responding counterparts in the VAX system as shown in Table 6-1. 
Come do not. Even some of the corresponding system services on 
the VAX do not operate in the same- way or provide the same 
information: 

I 

• 5CREPRC doesn't operate like ACT. A secondary 
activation can be done on the ModComp but can't 
using SCREPRC on. the VAX. 

e SGETJPI doesn't return the same information as 
GETTASK. 

• 9GETTIM returns time in a different format than 
GETTIME. 

• SQIO requires channel number as an argument/ not 
'.logical name as do the ModComp services. 

The total impact of this area on the GSSS software will remain 
unknown until the transport of the system is attempted. How- 
ever, secondary activations of tasks are common-place in the GSSS. 
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Table 6-1. ModComp vs. VAX System Services (1 of 3) 


Moccomp 

System 

Service 

VAX 

System 

Service 

ModComp 

Purpose • 

EST 

none 

Establish a resident task. 

heps 

none 

De-establish a task. 

ACT 

SCREPFC 

<0 

Start execution of a task. 

KILL 

SPORCEX 

Abort another task. 

ABORT 

SFORCEX- 

Abort this task. 

BOLD 

none 

Suspend task until 
resumed by operator. 

WAIT 

$ SOS END 

Suspend task until 
resumed by any resume. 

RES 

$ RESUME 

* Resume a task in WAIT. 

DELAY 

$SETIMR and 

Suspend a task for a 

* 

$WAITFR 

specified period of time. 

CONNECT 

none 

f 

Allocate timer to schedule 
any above function at a 
future time. 

GETTASK 

SGETJPI 

Get information about a task. 

SEND 

5QIO 

to a mailbox 

Send a message to another 
task. 

RECEIVE' 

$QIO 

Receive a message sent by a 

. 

from a mailbox 

SEND service. 

ALLOCATE 

SCRETVA 

Allocate a region of private 
memory to this task's space. 

DEALLOCATE 

5DELTVA 

Deallocate region of private 
memory from this task's space. 
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Table 6-1, ModComp vs. VAX System Services (2 of 3) 


ModComp 

System 

Service 

VAX 

System 

Service 

ModComp 

Purpose 

GREPRI 

none? 

Create shared region from 
this task's private space. 

INSPRI 

none? 

Insert shared region into 
this task's private space. 

GETTIME 

SGETTIM 

Get time of day or elapsed 
time. 

DUMP 

none 

Dump region of memory bo 
line printer 

. COLLECT 

none 

Parse next parameter in 
character string. 

ATCAN 

none 

Convert ASCII string to 
CAN-CODE. 

CANTA 

none 

Convert CAN-CODE to 
ASCII string. 

ATNUM 

none 

Convert ASCII string to 
binary. 

BTDEC 

none 

Convert binary to decimal 
ASCII string. 

STHEX 

none 

Convert binary to Hexa- 
decimal ASCII string. 

ASSX 

5CRELDG 

Assign logical name to 
device or file. 

TASSI 

5TRNLCG 

Test assignment of a logical 
name. 

REW 

5QIO 

Rewind a logical device. 

HOME 

?QIO 

Position a logical device at 
beginning of media (i.e. Rewind) 
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Table 6-1. ModComp vs. VAX System Services (3 of 3) 


ModComp 

System 

Service 

VAX 

System 

Service 

ModComp 

Purpose 

WHOP 

$QIO 

Wrika an end-o£-file mark 
on a logical device. 

TEBMIO 

? CANCEL 

Terminate an I/O request 
to device. 

ICWAIT 

none ? 

Wait for I/O to complete 

BKR 

5QIO 

Backspace a record on a 
logical unit. * 

AVR 

5QIO 

Advance a record on a 
logical unit. 

3KF 

?QIQ 

Backspace one file on a • 
logical unit. 

AVP 

?QIO 

Advance one file Pn a 
logical unit. 

READ 

$QIO 

Read a record from a 
logical unit.' 

WRITE 

5QIO 

Write a record to a 
logical unit. 

MESSAGE 

S3RDCST ? 

Display a message on the 
operators console. 

MESSAGE/HOLD 

none 

Display a message on the 
operator's console and 
enter a hold state. 
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SECTION 7 - CCNCLUSICNS 


Thi.3 report has presented many interesting peculiarities of the VAX 
11/780 system in relationship to the ModComp IV/35 implementation 
of the GSSS. Some of the software yithin the GSSS uses ModCcmp 
unique coding techniques and logic sequences that are contributing 
factors to the incompatibilities indicated. However , these incom- 
patibilities still exist with relation to the ModComp version of 
the GSSS. With this in mind the following conclusions about trans- 
porting the GSSS to the VAX sure presented: 

» 

• All of the tape I/O handling logic will require changes. 

• All of the file and device sharing logic will need 
modification. 

• All of the standard (256 byte) tape records will have 
to be redesigned to a different’ length. 

• The SOT input handler will have to be redesigned and 
rewritten. 

• Logic and coding techniques will have to be developed 
and implemented to avoid tile proliferation of disk files. 

• All end-of-file logic on random access disk files will 
have to be found and eliminated. 

• Any use of FORTRAN unformatted tapes will have to be 
eliminated. 
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• Most I/O to files will have to use the OPEN statement. 

• JCL logic sequences will require massive changes. 

• All use of the FORTRAN REWIND comnand for tapes will 
have to be eliminated. 

• All event messages will need to be routed through one 
module (process) . 

e Timing problems , particularly in the area of file OPEN/ 

CLOSE sequences r will need to be investigated. 

I 

e Most, if not all, character DATA statements in FORTRAN 
will have to be changed. » 

• All DATA statements in FORTRAN will have to be examined 

» 

for validity on the VAX. 

• All use of SHIFT, AND and OR logic for character manipu- 
lation will have to be eliminated. 

• Conversions of 32 bit integers to 16 bits will have to 
be examined and investigated. 

• Most ENCODE and DECODE statements in FORTRAN will need 
modification. 

• Array equivalencing will have to be closely examined 
for validity on the VAX. 
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• Any modification of DO LOOP variables within the loop 
will have to be eliminated. 

• Any conditionally executed statements within DO LOOPS 
will have to be carefully examined for valid execution. 

• New generalized methods for character manipulations 
will have to be developed. 

e- All of the assembler language modules will have to be 
rewritten using different logic sequences. 

e Most of the user written CSSS library routines will have 
to be recoded. 

• A method for specifying logical unit assignments in real- 
time will have to be developed. 

• The inconsistancies between the system services will / 
have to be resolved. 

Very few, if any, of the above conclusions will apply if the GSSS 
is transported to the ModCcmp CLASSIC system. Therefore, the main 
conclusion to be drawn from the State-of-the-Art Computer Systems/ 
GSSS Compatibility Study is: 

Transporting the GSSS to the ModComp CLASSIC system will require 

very few coding changes. However, attempting to transport the 

GSSS to the VAX 11/780 will require massive changes, not only 

in the coding of tne modules but also in the design of many 
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areas of the GSSS, particularly in the areas of I/O and task 
activation. 

In Fact, it may be a futile effort to attempt to implement any 
reed- time satellite ground support system like the GSSS on the 
VAX 11/780, since the basic philosophy in the '/AX environment is 
one of a multi-user, timesharing, interactive processor. 

To summarize the ModComp-to-VAX compatibility analysis, recall the 
conclusion from the MMS/GSSS MODCCMP Device and MAX IV Dependency 
Study. Based on the hypothesis of the compatibility of (1) FORTRAN 
language and compiler, (2) data base structure, (3) CRT page library 
and tables, (4) telemetry format tables, (5) command structures, and 
(S) all other internal tables, the approach to moving the GSSS to the 
target environment would be developed. This would entail at least 
rewriting the ModCamp/PORTRAN library routines (with the aid of a 

i 

cross-assembler) and moving the FORTRAN code with only the '’obvious'" 
changes made, followed by an iterative procedure of load/link/execute, 
error isolation, and error correction, until working code is produced. 

With respect to the VAX as a target machine, this minimal transport 
effort must, of course, be revised in light of the incompatibilities 
revealed in this study. The FORTRAN language and compiler incom- 
patibilities (in one case an outright bug in vendor software) obviate 
hypothesis (1) above and point to vast, detailed, and sometimes obscure 
changes in the GSSS FORTRAN code. Moreover, the FORTRAN semantic 
incompatibilities also imply incompatibilities in areas (2) through 
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(6) above. At the very least, GSSS internal structures involving 
manipulations of characters and hexadecimal codes will (most likely) 
be incompatible due to differences in internal byte and bit-string 
operations (logical or arithmetic). Examples of areas probably af- 
fected are the parsing software in the CRT page table and the command 
structure areas, and data base handling (i.e., do creation and ex- 
amination of structures "hide" differences between MOECCMP and 'PAX 
in data item encoding?). These points can be resolved only by de- 
tailed examination of the software in each of areas (2) through (6). 

Also in the language area, the significantly different philosophies 
in the organization of the assembly languages for the MODCCMP and 
VAX machines makes the cross-assembler approach to MODCCMP/PORTRAN 
library translation unproductive. Hence, complete, individual re- 
coding of these routines will have to be done. Furthermore, incom- 
patibilities in the VAX operating system and I/O software (i.e., 

» 

in JCL, system services, etc.) force re-coding and, in fact, re- 

i 

design of seme areas of the GSSS. Examples we have seen from these 
areas are: file and device sharing, 256-byte tape records, tape I/O, 
KCRT input handling, end-of-file handling for random access files, 
and disk file proliferation as a result of multiple task activations. 
A major problem lies in certain time-critical system actions: it is 
almost definite that the large OPEN/CLOSE time will cause severe 
degeneration of GSSS performance on the VAX, since each task activ- 
ation requires that the disk file containing the image be opened and 
closed. Also, the mailbox write/read time may be a problem, since 
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this will occur tor all event messages. Still another major problem 
is presented by secondary task activations: there is no system- 
supported method to do this on the VAX, and it appears that changes 
will be needed in ever/ such program (i.e., most programs). 

Thus, there are quite a few technical problems in the GSSS implement- 
ation on the VAX, with no clean, fast solutions. Most can be solved 
with detailed, item-by-item examination of the individual programs - 
a time-consuming and by no means guaranteed method of generating error- 
free software in one pass. Not surprisingly, the manpower estimates 
presented in the Dependency Study (1 1/2 man-years) must be revised. 

The best estimate at this stage is based on the STOL module implement- 
ation experience. This was a 2-man, 1 1/2-month effort for the trans- 
port of approximately 5000 lines of FORTRAN code. Allowing 1/2-month 
for learning the system, this amounts to a 2-man-month transport effort. 
The MMS/GSSS consists of approximately 100,000 lines of code, over ' 
33,000 lines of which are Assembler. For Assembler code, doubling the 
manpower effort per line of code, when compared to the STOL effort, is 
appropriate. So by extrapolation GSSS transport should require about: 

33.2 * 2-man-month3 * 66.4-man-months *5.6 man-years. 

Thus, as the latest rough estimate of human resources, the MMS/GSSS 
transport to the VAX-11/780 will require approximately 6-man- '/ears . 

This programmer resource coirmittment could be supported by the equivalent 
of one terminal, 40 hours per week for up to three progranmers, through 
three terminals, 40 hours per week for six or seven programmers, etc. 
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Finally/ consider the VAX hardware required to support the full GSSS, 
This is summarized as follows: 

Type DEC Supplied VAX Devices 


Tape Drives 


Two TU45 (1600/800 BPI, 9 trk, 75 IPS) 

Disk Drives 


One RMQ3 (67 MB, 1200 KB/S) 

KCRTs 


At least two (test conductor & page display) 

Printer . 


One IP11 (660 LPM) 

» 

Card Reader 


• 

One CRH (285 CPM adequate) 

Main Memory 

• 

* L MB, '600 nanosecond cycle time 


- (The GS$S on the VAX will require about 

750 KB since task swapping is not done 
as efficiently on the VAX due to the , 

t 

file OPEN/CLOSE timing). 

In addition/ specialized devices will have to be procured to replace 
the specialized devices that are in the current GSSS McdComp IV/35 
environment. 
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APPENDIX A - Obstacle* on the VAX and How They Were or Can be Overcome 


Obstacle 

Obstacle 

* 

Obstacle 

Obstacle 

Solution 


Obstacle 

Solution 

Obstacle 

Solution 


1: Character strings in FORTRAN DATA statements. 

2: FORTRAN ENCODE and DECODE statement differences. 

3; Hexadecimal constants in FORTRAN arithmetic 
expressions. 

4: Debug option character on FORTRAN statements. 

t 

(For obstacles 1 thru 4): Run the I'fTCV 

command procedure on t$* FORTRAN source. 

This procedure executes a combination of 
text editor CMP procedures and a FORTRAN 
’ program to modify the source code within 
the FORTRAN source {see G3SS/VAX USf?r3 Guide). 

5: Using the FORTRAN REMIND statement to rewind 

tapes . 

s Unknown 

6: The proliferation of data files used for output. 

; Use the OPEN statement specifying TYPE- 'OLD'. 
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Obstacle 7: 


Formatted tape I/O positioning. 


Solution 


Obstacle 

Solution 

Obstacle 

Solution 

Obstacle 

Solution 

Obstacle 

Solution 


: Use the JCL command procedures, AMOUNT, 3REW 

and ^DISMOUNT 

or 

Use OPEN statements and 5QIO system service 
calls (exact method unknown) . 

8; Unformatted tape incompatibility. 

• Unknown 

9 t Tape record lengths of 2S6 bytes. 

: Possibly using OPEN statement specifying 

* 

RECORDS I ZE- 25 6 , RECORDTYPE*' FIXED* . 

10: Carriage Control byte to tape drives. 

: Write a utility program to copy files 

circumventing the VAX carriage control 
to tape logic. 

11; Record and file positioning through JCL 
commands. 

; Write a utility program to accomplish 
this using SQIO system service calls. 
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Obstacle 

Solution 

Obstacle 

Solution 

Obstacle 

Solution 

Obstacle 

Solution 

Obstacle 

Solution 


12: Allowing many end-of-file marks on 

random access disk files. 

: Unkrcwn 

13: Sharing output files between processes. 

: Unknown - OPEN statement specifying SHARED 

doesn't work for output files. 

14: Sharing input files between processes. 

: Use OPEN statement fully specifying 

file name and SHARED. 

15: Integer overflew when converting 32 bit 

integers to 16 bits. 

: Compile FORTRAN program with /NCCHECK 

option . 

16: The use of SHIFT, AND & OR logic for 

character manipulation. 

: Eliminate all such logic and replace 

with ENCODE and/or DECODE statements. 
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Obstacle 17: 
Solution : 

Obstacle 13: 

Solution : 

Cbst to 1 * 19: 

Solution r 
Obstacle 20: 

Solution : 

Obstacle 21: 
Solution : 


Modification of CO LOOP variable within the loop. 

Recode 00 LOOP using IF statement to terminate 
the loop. 

Incorrect execution of conditionally executed state- 
ments within DO LOOPS when the FORTRAN is optimized. 

Recode DO LOOPS using IF statement to terminate 
the loop. 

* 

DEBUG can't run with shareable image , making 
testing while running in real-time very difficult. 

Unknown 

Being denied task activation rights because 
other task 3 have already been activated. 

Any task (process) that activates another 
task should receive all the necessary privi- 
leges necessary and the maximum quotas allowed. 

Retrieving the task status returns different 
information on the two machines. 

Status returned is CK in many cases? but for 
the others the solution is unknown. Some 
information is not available. 
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Obstacle 22: 
Solution : 

Obstacle 23: 
Solution : 

Obstacle 24: 

Solution : 
Obstacle 25: 

Solution : 

Obstacle 26: 

Solution: 


KCRT input works in character mode on the VAX 

Queue KCBT input until whole string is input 

(see Bill Mocarsky for exact details). 

Assembler languages totally incompatible. 

Other than redesigning and recoding all 
assembler modules the solution is unknown. 

m 

Specifying logical unit assignments when 
linking a module. 

Unknown 

Secondary activation of rc/Jdules while they 
are executing. 

Unknown, unless all modules hibernate or 
suspend themselves instead of exiting. 

Printer output lines written directly 
from different modules. 

Modify them to route all printer output 
through one process. 
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Obstacle 27: 
Solution : 

Obstacle 28: 

Solution : 
Obstacle 29: 

Solution 
. Obstacle 30: 

Solution: 


Differences in array equivalencing in FORERAN. 

One by one examination of the use of the 
arrays equivalenced and modification where 
necessary. In some cases there may be no 
known solution. 

The length of time it takes to accomplish an 
OPEN/ CLOSE sequence for a disk file on the VAX 
(314- mis). 

Unknown 

» 

The length of time it takes to pass messages 
between processes on the VAX using mailboxes 
(0.4 mis). 

v 

Unknown 

The differences between data types in DATA 
statements in FORTRAN: e.g. DATA I/Z2031/ * 

DATA I/’ 1'/ on the ModComp but not on the VAX. 

One by one examination of hexadecimal constants 
in DATA statements for validity and modification 
where necessary, 
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APPENDIX B - Benchmark Teats and Their Purpose 


Benchmark 

Name (number) Purpose 


TSTAPF (1.1, 1.3) Test order of formatted character 

transfers during I/O. 


TSTAPU (1.2) 


LOGIGALS (1.4) 


TSTFXLS (2.1, 2.3) 

TSTAPF and 
TSTAPU i 2.2) 

TIMEOPEN (2.4) 


Test order of unformatted character 
transfers during I/O. 

Test if logical unit assignments must 
be the same for each process in the 
group (JCL sequence). 

Test sequential disk file access. 

Test effect of end-of-file on tape. 

Time OPEN/CLOSE sequence over- 
head for disk files. (314 jnls) 


JCL sequence (2.5) 


Test need for tapes to be MCUNTed from 
code. 


TSTFILCJ (3.1, 3.2, 3.3) Test random disk file access. 


TSTFILF and Test blocking and deblocking 

TSTFILU (3.4) 

of disk file records. 
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Benchmark 
Maine (number) 


Purpose 


EQUIV (5.1) 

TWODIM (5.2) 

BXTESIGN (5.3) 

STOL (5.4) 

DATCCM (5.6, 5.7) 

BUFFIO (5.8) 

LLSQ (5.9) 

STOL ate. (6.1) 
STOL etc. (6.2) 
ASIT (6.3) 


Test effect of EQUIVALENCE statement 
on 1*2 and 1*4 arrays in FORTRAN. 

Test memory layout of 2 dimen- 
sional arrays in FORTRAN. 

Test if VAX treats bytes as signed 
integers. 

Test if FORTRAN functions . 
recognize different data types. 

Test effect of DATA statements in 
FORTRAN for HEX, ASCII & decimal data. 

r 

i 

Test if BUFFIO routine can be 
written for the VAX. 

Test results of least squares polynomial 
fit on both the ModComp and the VAX. 

Test compatibility of system services. 

Test use of shared regions. 

Test spooling of event messages 
in chronological order. 
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Benchmark 
Name (Number) 


Purpose 


TIMEOVER (6.4) 

SNDMSG and 
RECVMS (6.6) 

TSTAPF (6.7) 

TIMEMBOX 

TIMEFORT 

TIMEIO (4.0) 

TIMEPOLJf 


Time system service call overhead.' 
(0,07 mis) 

Test how mailboxes work on the VAX. 

Test I/O error handling on the VAX. 

Time mailbox read/write sequence. 

1 (0.4 mis) 

Time FORTRAN subroutine call overhead. 
(0.02 mis) 

Time I/O to disk file 

(read * 3.3 mis, write * 4.0 mis). 

Time 5th order polynomial evaluation 
(Horner's method » 0.11 mis, 

POLJf instruction ■ 0.02 mis). 
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